I do believe I have it fixed. I am unsure of what caused the problem but I am leaning to some corruption introduced when upgrading from 5.09a to 6.0. I traced the problems back to when I did the upgrade. I have another identical server in my cluster without any problems (the only difference is that I did a clean install on this one and then moved the data over from the R5 server it was replacing)(both machines are Dual 900MHZ processors with 1GB/Memory running Windows 2000 Server SP3). I had downgraded my server one step at a time all the way down to 6.0 to try and resolve this issue, each time deleting the log.nsf and all the mail.box's and running fixup and compact with all different types of switches but the corruption still occurred. I finally blew away the server and installed a fresh installation without any files on the server, this allowed it to create all new files. I then copied my ID, INI, and only databases that were specific to us. (I did not overwrite system databases unless they had some data specific to us) Before starting the server I ran compact -D on the entire data directory to delete all view indexes in all databases. I then started up the server and this is what I noticed:
The databases still had a last modified date in the future, but these dates were not changing anymore like they previously were. (previous to rebuilding the server, every time you accessed the database and made any modifications the date would move forward...so the database and new documents would never catch up with the date) Because they were now not changing I waited and watched. As soon as the date/time approached the database started working totally normal. The last modified date of the database stayed current and all documents created now had a current date/time in the last modified (in this file) property. So, needless to say, replication is working correctly again and the view indexes are now keeping current. I do have one very busy mail database (a SPAM catchall mail database) that the modified date was over 10 days in the future so I will have to wait for those 10 days to see it work correctly again (I don't know any other way to do this other that creating new replica's) Based on this date being so far off I think it looks like this date issue is somewhat related to the old creep issue they had back in R4 and early R5 days >>
http://www-10.lotus.com/ldd/46dom.nsf/55c38d716d632d9b8525689b005ba1c0/bee483d6ce4fa0eb85256aa20079725e?OpenDocument
http://www-10.lotus.com/ldd/46dom.nsf/55c38d716d632d9b8525689b005ba1c0/7a5d707932c13ea485256cec005ebdc4?OpenDocument
http://www-10.lotus.com/ldd/46dom.nsf/55c38d716d632d9b8525689b005ba1c0/eb949af08fbd6602852567fd000559a9?OpenDocument
http://www-10.lotus.com/ldd/46dom.nsf/55c38d716d632d9b8525689b005ba1c0/31aa44556337a71c852567300073b0a6?OpenDocument
And a Lotus Tech Document >>
http://www-1.ibm.com/support/docview.wss?rs=203&q=time+creep&uid=swg21089161&loc=en_US&cs=utf-8&lang=en+en
Return to top
. . . . . . . . . . [FIXED] Upgrade issue - "Database t... (~Bella Fezkroko... 7.Aug.03)
Print this page
